Add Book to My BookshelfPurchase This Book Online

Chapter 5 - Adding Support for Legacy LANs

Cisco TCP/IP Routing Professional Reference
Chris Lewis
  Copyright © 1999 The McGraw-Hill Companies, Inc.

Novell NetWare's IPX/SPX Protocols
Novell's NetWare product, which is installed in more than 50 percent of LANs worldwide, uses the IPX/SPX (Internetwork Packet Exchange and Sequenced Packet Exchange) protocol as its basis for communications. NetWare was designed as a departmental server operating system, originally meant to service up to 100 users. Novell's marketing strategy was to aim for the departments that did not want to wait in line for corporate MIS departments to deliver systems that they could instead buy off the shelf. This strategy was well-timed—it coincided with cheap, powerful PCs becoming available—and became phenomenally successful.
To make it as easy as possible for departments to implement a LAN protocol, Novell designed the IPX/SPX protocols, which eliminate the need to number individual nodes in a network. Because it was assumed that NetWare would be implemented in an environment in which all nodes were connected via a high-capacity Ethernet LAN, NetWare designers also programmed a number of features into the original NetWare Core Protocol set that made it easy to connect a NetWare LAN, but fairly costly in terms of bandwidth utilization.
As a result of NetWare's success, IPX became a de facto standard and many third-party developers developed applications for it. This was all well and good until it became necessary to transport NetWare traffic over wide area networks that do not have the bandwidth available that an Ethernet LAN does. To resolve these issues, protocols such as the NetWare Link State Protocol and IPXWAN were developed.
NetWare is a client/server system; as such, all communications pass between the client software on a workstation PC and the server. Client PCs do not communicate directly. This contrasts with the TCP/IP communications model, which is designed to allow any machine to send information directly to any other machine without the need to go to a central server first. The TCP/IP communications model is often referred to as peer-to-peer networking.
We will look at an overview of NetWare protocol technology before discussing specific router implementations of these protocols.
Overview of IPX and SPX
IPX and SPX span the layer 3 and layer 4 protocol functions in OSI terms and, as such, do have fields in the header for network numbers. IPX is a connectionless datagram protocol, similar in many ways to IP; SPX provides connection-oriented delivery similar to TCP. A packet containing an IPX destination and source address also will contain the MAC destination and source in the layer 2 header, as previously described for TCP/IP communications. The major difference between NetWare and TCP/IP implementations is that on a NetWare LAN, you assign a network number for a given segment and all nodes use their MAC address in combination with this network number to generate their own station address. In TCP/IP every workstation is given an IP address, and the network number is derived from that value and any subnet masks applied.
The IPX header always starts with the hexadecimal value FFFF. The IPX header is somewhat similar to an IP header, carrying essentially the same information. The key information carried is as follows:
  Destination network, node and socket numbers
  Source network, node and socket numbers
  Transport Control byte
  Length of IPX header and data
These are fairly self-explanatory, except for the Transport Control byte. To propagate route information, IPX uses a version of RIP that closely resembles that implemented by the Xerox Networking System. As with other RIP implementations, the maximum number of hops a packet is allowed to traverse is 15, and the 16th router will discard the packet. When a packet is originated, this value is set to 0 and is incremented as the packet passes through each successive IPX router. As you can see, the IPX Transport Control byte performs the same function as the IP Time To Live field.
The destination network value is obvious; however, this value is set to 00-00-00 if the destination server is on the same network number as the client sending the packet.
The destination node address has a differing value depending on whether a NetWare client or server is sending the packet. If the packet was sent by a server, it will contain the destination workstation's MAC address, and if it was sent by a workstation to a server, it will contain the value 00-00-00-00-00-01. It must be noted that the MAC information in the layer 2 header will contain the appropriate MAC address for the destination machine, whether that is a server or a workstation.
Source and destination sockets are used in IPX/SPX communications in the same way as in TCP/IP, i.e., a socket identifies the address of a program running in a machine.
SPX adds additional fields to the layer 3 header, which include source and destination connection IDs, and sequence and acknowledgment numbers. Since SPX operates as a connection-oriented protocol, it operates on a handshake principle to initiate and close connections, similar to TCP.
With SPX, a constant stream of traffic between the client and server is generated by the protocol and is independent of any user data that needs to be transmitted between the two. This stream of traffic uses timers to decide when to re-request responses if none are received. The timers you may wish to adjust on the workstation or server software are:
  SPX listen timeout
  SPX verify timeout
  SPX abort timeout
  SPX Ack wait timeout
  SPX watchdog verify timeout
  SPX watchdog abort timeout
In Novell documentation, the default values for these timers are given in ticks, with one tick being the standard PC clock tick, roughly /18th of a second.
NetWare Client-to-Server Communication
The NetWare client protocols are implemented in two parts: The first is the IPX/SPX protocol, the second is the shell, or redirector. Applications that need only to use the services of IPX/SPX need only to load the first part (typically the IPXODI.COM file). To communicate with a NetWare server, the NetWare shell or redirector must be loaded as well. The purpose of this shell is to intercept all requests from a workstation application and to determine if the request will be serviced by the local OS or the server resources.
The workstation shell handles all interaction with the server, including interpreting route information and server service advertising. Novell did a good job with the design of this software, given its intended market, because it hides the process of address assignment and routing issues from the person installing the network. There is a price to be paid for this, however. The price paid is in the amount of network bandwidth consumed by the Service Advertising Protocol (SAP), Routing Information Protocol (RIP), and NetWare Core Protocol (NCP), roughly in that order.
The NetWare Core Protocol is the language that NetWare clients and servers use to talk to one another. Typical NCP functions are to deliver file reads or writes, set drive mappings, search directories, and so forth. Novell does not publish many details about NCP because it is considered to be confidential.
The area of NetWare communications that is of most interest to us is the Service Advertising Protocol (SAP). It is via SAPs that a workstation finds out what servers are available on the network to connect to. There are three types of SAP packet:
  Periodic SAP information broadcasts
  SAP service queries
  SAP service responses
In essence, the SAP information broadcasts are used to advertise information that a server has within its bindery if it is a NetWare 3.x server, or NetWare Directory Service (NDS) if it is a 4.x server. A NetWare server's bindery is a flat-file database of resources and clients on a network, whereas the directory service keeps this information as objects in a hierarchical database. These SAP broadcasts occur by default every 60 seconds.
When a service is broadcast, it is given a server type number, the most common of which are listed as follows:
Type
Function
4
File server
7
Print server
21
NAS SNA gateway
98
NetWare Access Server
With many (more than 20) NetWare servers interconnected, the size of these SAP broadcasts can become troublesome for heavily utilized WAN links. Overutilization during broadcast phases can cause packets to be dropped by a router attempting to forward traffic on the link.
The service queries performed by SAP are executed when a workstation wants to find a particular service on the network. Service queries effectively are queries of the network database file kept on the server (be this a bindery or directory service). The most common example of this is the Get Nearest Server query.
When a client starts the NetWare shell, a Get Nearest Server SAP is broadcast on the network, and either a NetWare server or router can answer these broadcasts. When this broadcast is sent out, all servers on the network reply, but the client will establish a connection only with the first one to reply. The first to reply will not necessarily be the server defined as the "preferred" server in the client's configuration. In this case, the workstation will connect to the first server to reply, just to query its database to find out how to get to the preferred server.
The IPX header previously described has a destination network number field that is used for routing purposes. NetWare servers and routers provide information on the networks they know about by using a version of RIP, in the normal distance vector protocol fashion, via broadcasts. This routing information is contained in routing information tables located at each router and server on the internetwork.
NetWare's RIP operates much the same way as does the RIP version 1 described previously for IP networks. RIP update broadcasts are sent out when a router initializes, when specific route information is requested, periodically to maintain tables, when a change occurs, or when a router is going down. In addition, NetWare RIP employs Split Horizon, although Poison Reverse and hold-down timers are not used. The metric used by NetWare RIP is the number of ticks to get to a destination. If two routes have the same tick value, the number of hops is used as a tie-breaker. This is an improvement on IP RIP, as the tick value is a better measure of the speed of delivery of a given route.
RIP is used on initial startup of the client shell. After the SAP Get Nearest Server broadcast sequence is completed, and the quickest server replies first, the workstation must find a route to that server. This is achieved by using the RIP request broadcast. When this broadcast is sent out, the workstation is requesting route information for the network number it needs to reach. The router servicing routes to this network number will respond.
Configuring Basic IPX Routing
With few exceptions, Cisco's implementation of Novell's IPX provides full routing functionality. The only part that is proprietary to Cisco is the use of IPX over X.25 or T-1 connections. For these connections, you must have Cisco routers on both ends of the connection.
One of the most useful features of Cisco IPX routing is that you can use EIGRP as the routing protocol. EIGRP provides automatic redistribution between RIP and EIGRP domains, the opportunity to traverse up to 224 routers in a network, and use of incremental SAP updates. Incremental SAPs are used when EIGRP routers exchange information. Because EIGRP utilizes a reliable transport mechanism for updates, a router does not need to continuously send out all SAP information in regular broadcasts. With incremental SAPs, SAP information is sent out only when it changes.
Assuming that you have a version of Cisco IOS loaded that is licensed to run IPX, the first task involved in getting IPX routing functional is to use the global ipx routing command as follows:
Router1(config)#ipx routing
Once this is done, IPX network numbers can be assigned to the router's interfaces. Care must be taken when installing a new router on an existing IPX network. If one of the router's interfaces is connected to an existing IPX network with an address that does not match that already in use, the NetWare servers will complain, displaying error messages that another device is disagreeing with them. This situation stops the new router from participating in IPX routing on the network.
When the IPX network number is assigned, you have the opportunity to define the encapsulation type used for frames on that interface. This is of particular interest on an Ethernet LAN interface, in which the encapsulation used for the layer 2 Ethernet frame can take any one of four values.
By default, NetWare servers prior to version 4 used a Novell-specific implementation of the IEEE 802.3 Ethernet frame. This type of frame only supported IPX as the network layer 3 protocol. To use this type of encapsulation for an Ethernet port, type the following (assuming that we use an IPX network number of 5):
Router1(config)#interface E0
Router1(config-int)ipx network 5 encapsulation novell-ether
Note that the Ethernet encapsulation is specified for the IPX protocol on this interface, but other protocols such as IP may be routed on this interface using a different encapsulation.
On many LANs, TCP/IP connectivity had to be added after the original IPX installation. The default NetWare frame type could not support TCP/IP, so many network administrators configured their NetWare servers to use both the default and Ethernet_II frame type for IPX communications. This allowed individual client workstations to be migrated from Novell 802.3 to Ethernet_II. The drawback is that it doubled SAP, RIP, and other NetWare administration packets on the network, so typically Novell 802.3 was removed from the server when all workstations had been converted to Ethernet_II.
To change the Ethernet encapsulation on an Ethernet interface to Ethernet_II, perform the following:
Router1(config)#interface E0
Router1(config-int)#ipx network 5 encapsulation arpa
Novell realized that the single protocol restriction of its proprietary encapsulation was a significant drawback, so for NetWare 3.12 and 4.x Novell changed the default encapsulation to conform to the 802.2 standard.
To implement this encapsulation on an Ethernet interface, input the following configuration:
Router1(config)#interface E0
Router1(config-int)#ipx network 5 encapsulation sap
The final encapsulation is rarely used for Ethernet interfaces, but you may come across it. It is the Sub Network Access Protocol (SNAP). Ethernet SNAP can be configured as follows:
Router1(config)#interface E0
Router1(config-int)#ipx network 5 encapsulation snap
The way to determine which encapsulation is running is to use the show interface command that we have seen before. The encapsulation type is given on the fifth line of the display for an Ethernet interface.
Viewing Potential Problems
By enabling global IPX routing capability and assigning a network number to interfaces, the basic configuration for a Cisco router to participate in IPX routing is complete. It is only now, however, that the real work begins in order to get IPX routing working efficiently over a variety of network media.
We need to explore some commands that will show us potential problems and see the effects of optimization commands that we will execute. The first (and often the most telling) command display is that shown by issuing the show ipx servers command, shown in Fig. 5-1.
This shows the servers advertising SAP messages to the router. If this display is empty and you know there are functional NetWare servers on the same LAN as the router, it is a good indication that the encapsulation set on the router is different from that used by the servers to adver-tise SAPs. As you can see, the same server can advertise a number of services; for example, server NWARE1 advertises many services, including types 4, 107, 115, 12E, 12B, and 130. The show ipx servers command output also tells you the source of the information (in this case all entries are by periodic updates), the source network, node number and port number of the entry, route metric in terms of ticks and hops, and the interface through which it is reachable.
router1>show ipx server
Codes: S - static, P - periodic, E - EIGRP, N - NLSP, H - Holddown, + = detail
11 total IPXservers
Table ordering is based on routing and server info
Type
Name
NetAddress Port
Route
Hops
ITF
P
4
Nware1
789A.0000.0000.0001:0451
2/01
1
E0
P
4
Nware2
78A.0000.0000.0001:0451
3/02
2
E0
P
4B
SER4.00-4
789A.0000.0000.0001:8059
2/01
2
E0
P
77
Nware1
789A.0000.0000.0001:0000
2/01
2
E0
P
107
Nware1
789A.0000.0000.0001:8104
2/01
2
E0
P
115
Nware1
789A.0000.0000.0001:4005
2/01
2
E0
P
12B
Nware1
789A.0000.0000.0001:405A
2/01
2
E0
P
12E
Nware1
789A.0000.0000.0001:405D
2/01
2
E0
P
130
Nware1
789A.0000.0000.0001:1F80
2/01
2
E0
P
23F
Nware1
789A.0000.0000.0001:907B
2/01
2
E0
P
44C
1095U1
789A.0000.0000.0001:8600
2/01
2
E0
Figure 5-1: Screen output of the show ipx servers command
It is quite easy for periodic SAP advertisements to completely overwhelm a WAN link for many seconds. Let's perform some calculations to show how this happens. A SAP packet can contain up to seven 64-byte entries, which, along with IPX and other information, gives a total of 488 bytes. Let's say that, including file servers, database servers, and print servers, there is a total of 50 NetWare devices on an internetwork. Each NetWare device typically will be advertising 10 different SAP services, giving a total of 500 SAPs. If we are using a 64 kbps line, let's work out the impact these regular SAP updates will have.
For 500 SAPs you need a total of 72 packets (71 packets each carrying 7 SAPs  and 1 packet carrying 3 SAPS).
This means that for the fully loaded advertisements we need 71x488 = 34,648 bytes, plus 49 bytes for the one partially filled SAP packet, for a total of 34,697 bytes.
To convert this in to a number of bits, multiply by 8, which gives us a total of 277,576 bits.
This can be viewed in two ways. First, we know these updates are sent out every minute, so we can work out the bits sent out per second to get the amount of bandwidth consumed by the updates. This is 277,576/60 = 4626 bits per second.
Alternatively, because these updates are sent out all at once every 60 seconds, we can see how long it will take to send this number of bits. This is calculated as follows;
277,576 bits / 64 kbps = 4.4 seconds
Therefore with this many SAPs communicating on a 64 kbps line, you know that for at least 4.4 seconds out of every minute, total bandwidth will be consumed by the SAP advertisements.
Now let's look at the regular RIP updates. To view the known routes, issue the show ipx route command shown in Fig. 5-2, which also gives an explanation of the display entries.
router1>show ipx route
Codes: C - connected primary network, c - connected secondary network
S - Static, F - Floating static, L - Local (internal), W - IPXWAN, R - RIP, E - EIGRP, N - NLSP, X - External, s - seconds, u - uses
3 total IPX routes. Up to 1 parallel paths and 16 hops allowed
No default route known
800(SAP)E0
111(PPP)As1
789A[03/02] via890.0000.0010.062a30sE0
Figure 5-2: Screen output of the show ipx route command
This display is similar to the IP routing table examined earlier. The table shows how the route was discovered, what the network number is, which interface is nearest that network, and the next hop, if appropriate.
Each RIP update contains 40 bytes of header and up to fifty 8-byte network numbers. If there are 200 RIP routes, we get four full RIP packets, which is 4x440 = 1760 bytes. To convert this into bits, we multiply by 8, which yields 14,080. If you divide 14,080 by 60, this is 235 bits per second. Transferring this amount of data at 64 kbps speed takes less than a second, so you can see that SAP updates are far more of a concern than are RIP updates.
To view a summary of the IPX traffic that has passed through this interface, issue the show ipx traffic command shown in Fig. 5-3.
router1>show ipx traffic
System traffic for 0.0000.0000.0001 System-Name: router1
155098 total, 40 format errors, 0 checksum errors, 0 bad hop count, 90 packets pitched, 90212 local destination, o multicast
90345 received, 14789 sent
1333 encapsulation failed, 305 no route
470 SAP requests, 231 SAP replies, 7 servers
18332 SAP advertisements received, 7200 sent
0 SAP flash updates sent, O SAP poison sent
0 SAP format errors
439 RIP requests, 403 RIP replies, 3 routes
59338 RIP advertisements received, 4769 sent
620 RIP flash updates sent, 0 RIP poison sent
0 RIP format errors
Rcvd 0 requests 0 replies
Sent 0 requests, 0 replies
760 unknown: 0 no socket, 0 filtered, 33 no helper
0 SAPs throttled, freed NDB len 0
Figure 5-3: Screen output of the show ipx traffic command
This display is useful for viewing the amount of traffic generated by all the different types of NetWare communications protocols. It shows 158,054 packets received, of which 18,644 were SAPs. This is normal, but if SAPs become 20 percent of traffic, you should seek to reduce the SAPs by the methods discussed later in this chapter.
Optimizing IPX Routing and Service Advertising
There are many ways to reduce the overhead of IPX-based communications on an internetwork. You will get the best return immediately by setting up an access list that restricts transmission of SAPs over the wide area link to only those that are absolutely necessary. A typical access list and its application are shown as follows:
interface Ethernet0
ipx input-sap-filter 1000
!
access-list 1000 permit 123.0000.0000.0001 4
The first entry is part of the configuration for the Ethernet 0 port, and applies access list number 1000 to any packets coming into this port. The second section is the access list itself. This access list permits the device on network 123 with the IPX address of 0000.0000.0001 to pass type-4 SAPs only. If the 4 were omitted, the list would allow the Ethernet port to pass all SAPs from this device. Clearly this device is a NetWare server, as all NetWare servers use the value 0000.0000.0001 for their internal node address. The result of applying this access list is that computers on the other end of this WAN link will hear only about this server on network 123.
This is what is known as a SAP access list, and is identified as such because it is numbered in the range 1000 to 1099. SAP access lists can be applied as input or output filters. If this list were being configured on an access router providing dial- up services, you would have a choice of applying an input filter on the Ethernet interface, which restricts the SAPs coming into the router and limits the entries in the output of the show ipx servers command, or placing an output list on each dial- up interface in use.
Applying an input list as shown in this example requires only one entry in the configuration of the Ethernet interface, but does restrict all other asynchronous interfaces on the router to being capable of connecting only to this one server. Applying an output list on each dial-up interface means that the router perceives all other servers on its Ethernet interface, giving you the flexibility of allowing different dial-up interfaces access to different IPX servers. However, it requires more work to configure access lists for each dial-up interface.
The next type of access list to add to further reduce WAN traffic is a network filter list to restrict which networks are added to the routing table and hence reduce the size of IPX RIP updates sent out every minute. The configuration to achieve this is shown as follows:
interface Ethernet 0
ipx input-network-filter 800
!
access-list 800 permit 234
In this example, standard access list 800 (standard access lists go from 800 to 899) permits routing updates from network 234, but denies all others.
If you are able to restrict WAN traffic to only those SAPs and RIP updates that are necessary for the remote servers and workstations to function correctly, you have gone a long way toward optimizing your internetwork, although there is more that can be done. As previously stated, SAP and RIP updates are sent out every minute; with many updates to be sent out at once, this update traffic can fill up all available bandwidth, cause buffers to fill, and in the worst case, cause the router to drop packets entirely. To alleviate this situation, you can have the router introduce a delay between SAP and RIP packets being sent out.
You can set the interpacket delay for SAPs by using the ipx output-sap-delay command. This command is configured on a per-interface basis and specifies the delay between packets in milliseconds. Novell recommends a value of 55 milliseconds for a Cisco router, because some older NetWare servers cannot keep up with Cisco's default delay of 0 milliseconds. If the problem you are trying to solve is related to WAN utilization, the best delay value to use will depend on the routers, traffic patterns, and links in use. Trial and error is the only real answer, but a value of 55 milliseconds is probably as good a starting point for experimentation as any.
The final thing you can do to optimize IPX SAP communication over a WAN link is to increase the amount of time between SAP updates. By using the ipx sap-interval command, you can set the SAP update period on specified WAN interfaces higher than the 1-minute default. NetWare workstations and servers on LANs require SAP updates every minute. As WAN interfaces typically connect two routers together over one link, you can configure the routers to exchange SAPs at intervals greater than a minute. The ipx sap-interval command can be applied to the router interfaces on both ends of a link to reduce WAN transmission of SAP information while maintaining the regular 1-minute updates on LAN interfaces for the NetWare workstation and servers. An example of the use of this command is:
interface serial 0
ipx sap-interval 10
This configuration sets the SAP update interval to 10 minutes for SAPs being sent out the Serial 0 port. A similar command, ipx
update-time, can be used to increase the interval between RIP updates over a WAN link. This is an example of increasing the RIP update timer to 2 minutes:
interface serial 0
ipx update-interval 120
An alternative to relying on dynamic processes like RIP and SAP advertisements to control NetWare networking is to create static routing tables. This has the advantage of eliminating WAN bandwidth utilized by these protocols and is simpler to set up than configuring packet delays (which must be the same on all routers) and access lists. The down side is that routing information does not adjust automatically to link or other network failures. Static routing can be implemented by the use of the ipx route and ipx sap commands. Use the following to add a static route to the routing table:
Router1(config)#ipx route aa abc.0000.0010.2345
The aa in this command refers to the network number for which you wish to add a route. This is followed by the network number and node address of the device to use as the next hop to get to this network. The command structure and concept are exactly the same as adding a static route for a TCP/IP internetwork.
Static IPX SAP entries are added using the ipx sap command. Each static SAP assignment overrides any identical entry learned dynamically, regardless of its administrative distance, tick, or hop count. Within the ipx sap command you must specify the route to the service-providing machine. The Cisco router will not add this static SAP until it has learned a route to this machine, either by an IPX RIP update or a static route entry. An example of this command follows:
Router1(config)#ipx sap fserver 4 543.0000.0010.9876 451 1
This command first specifies the name of the machine to add to the SAP table, in this case fserver, which is then followed by the network number and node address of this machine. This information is followed by the IPX socket used by this SAP advertisement and the number of hops to the machine specified.
One final option to look at for reducing the bandwidth used by regular SAP and RIP updates is snapshot routing, which is a time-triggered routing update facility. Snapshot routing enables remote routers to learn route and SAP information from a central router during a prespecified active period. This information is then stored for a predefined quiet period until the next scheduled active period. In addition to specifying the active and quiet periods, a retry period also is set for snapshot routing. This retry period comes into effect if no routing information is exchanged during an active period, and is in place so that a device does not have to wait for an entire quiet period if routing information is missed during an active period.
Snapshot routing is implemented via the snapshot client on one side of the WAN link and snapshot server command on the other side of the WAN link.
Optimizing Periodic NetWare Maintenance Traffic
Novell NetWare is a complete network operating system and, as such, utilizes periodic updates in addition to those generated to keep routing and service tables updated. Although these updates do not consume significant bandwidth, they can be annoying if a dial-on-demand routing (DDR) solution is chosen for economic reasons. Clearly, if a local NetWare server is constantly sending updates to a remote server, the DDR link will be established and costs incurred even when no user data needs to be transmitted. These periodic updates comprise the following:
  NetWare IPX watchdog
  SPX keep-alives
  NetWare serialization packets
  NetWare 4 time synchronization traffic
The NetWare operating system has many protocols that are considered part of the NetWare Core Protocol; watchdog packets are considered part of the NCP set. The purpose of the watchdog packet is to monitor active connections and to terminate connections if the client machine does not respond appropriately to a watchdog packet request. The only two parameters of interest that can be altered for the watchdog service defined on the NetWare file server itself are in the AUTOEXEC.NCF file as follows:
set delay between watchdog packets = y
set number of watchdog packets = z
The default for y is 59.3 seconds, but can vary between 15 seconds and 20 minutes. The default for z is 10, but is configurable anywhere between 5 and 100. Clearly if these values are increased, less use will be made of WAN links by the watchdog protocol.
In place of changing these parameters on the server, you can configure a router to respond to the server's watchdog packets on behalf of a remote client. This is termed IPX spoofing. The obvious downside to doing this is that a router local to the NetWare server may keep connections open for remote client PCs that are in fact no longer in use. The effect this has is to use up one of the concurrent user accesses allowed within the NetWare server license. (Typically a NetWare server is sold with a license for 100 or 250 concurrent users.) To enable IPX spoofing, input the following global configuration command. (There are no arguments to specify for this command.)
Router1(config)#ipx watchdog spoof
The next periodic update we will examine is the SPX keep-alive. SPX is a connection-oriented protocol typically used by a network printer process (such as RPRINTER) or an application gateway (such as Novell's SAA gateway). To maintain an SPX connection during periods when no data is transmitted, both ends of an SPX connection transmit keep-alive messages every 3 seconds by default. (This is the NetWare 3.x default; NetWare 4.x sends SPX keep-alives every 6 seconds by default.) Keep-alive values on the server side cannot be user-configured, but they can be set on the client side, from a default of every 3 seconds up to one keep-alive every hour. An alternative to changing this default in the NetWare software is to implement SPX keep-alive spoofing on Cisco routers positioned between a client PC and NetWare server. Consider Fig. 5-4.
Figure 5-4: Network configuration for IPX/SPX spoofing
In this illustration, router 1 is spoofing onto IPX network A for the NetWare server and router 2 is spoofing onto IPX network C for the client PC SPX processes, and SPX keep-alives are kept off the WAN. SPX spoofing is implemented using the following global configuration commands:
Router1(config)#ipx spx-spoof
Router1(config)#ipx spx-idle-time 90
The first command enables SPX spoofing and the second command specifies the amount of time in seconds (90 in this case) before spoofing of keep-alive packets can occur.
Novell implements a 66-second unicast to all servers on the same internetwork to provide for comparison of license serialization numbers on servers in use. This is there to protect Novell from a user reinstalling the same software license on multiple servers on the same internetwork. If a serialization packet is detected that has the same license number as the server receiving the packet, a server copyright violation message is broadcast to all users and the NetWare server consoles. There are no specific commands to stop these packets within the Cisco IOS, and the only way to block these serialization packets traversing a WAN is to use an access list.
NetWare 4.1 Considerations.     The main administrative problem with NetWare 3 was that user accounts were defined on a per-server basis. In a LAN servicing several hundred or more users, several NetWare servers would have to be deployed and users would have to be given specific accounts on every NetWare server to which they needed access. This forced network managers to implement a maze of login commands to enable each user to get access to all the shared data needed.
To eliminate this problem, Novell introduced NetWare Directory Services (NDS), which replaced the flat-file user information database (the bindery) with a hierarchical, object-oriented replicated database. The advantage is that with the same database of user information on every server, a user can gain access to all resources needed with just one logon. With replication comes the problem of ensuring synchronization among these databases. To ensure synchronization, NetWare 4.1 timestamps each event with a unique code. (An event is a change to the database.) The timestamps are used to establish the correct order of events, set expiration dates, and record time values. NetWare 4.1 can define up to four different time servers:
  1. Reference time server passes the time derived from its own hardware clock to Secondary time servers and client PCs.
  2. Primary time server synchronizes network time with reference to at least one other Primary or Reference time server.
  3. Secondary time server receives the time from a Reference or Primary and passes it on to client PCs.
  4. Single-reference time server is used on networks with only one server and cannot coexist with Primary or Reference time servers. The Single-reference time server uses the time from its own hardware clock and passes it on to Secondary time servers and client PCs.
This synchronization of time between servers across a network can add to network congestion and activate dial-on-demand links unnecessarily. Novell offers a TIMESYNC.NLM program that can be loaded on a NetWare 4.1 server to reduce the amount of time synchronization packet traffic. The best way to limit the amount of this type of traffic over WAN links is to locate time servers appropriately on the network (Fig. 5-5).
Figure 5-5: Locating NetWare time servers on an internetwork
In this internetwork, there is one Reference time server, SA. This will supply time synchronization to servers SB and SC. Server SC will, in turn, supply time synchronization to server SD. Because SC was made a Primary time server, it is the only server that needs to communicate with the Reference server on network Y.
Configuring EIGRP for IPX
We already have discussed how RIP in the IP world can provide less-than-optimal routing. The same is true of RIP in the world of IPX routing. If you are implementing IPX over a wide area network, you should consider making the WAN routing protocol EIGRP. EIGRP is more efficient and provides quicker network convergence time over router-to- router links than does IPX RIP. Because NetWare servers can only understand IPX RIP, however, we have the same issues in the Novell world as we did in the IP world when connecting Unix machines to an IGRP WAN.
We can make EIGRP the routing protocol for the WAN links, and use either static routes on the NetWare servers or redistribution on the routers, to enable the Novell servers to participate in routing across the WAN. To define IPX EIGRP on a Cisco router, enter the following commands:
Router1(config)#ipx router eigrp 22
Router1(config)#network aaa
The first line defines the IPX EIGRP routing process on the router to be part of autonomous system number 22. The second (and potentially subsequent lines defined) identifies the IPX network numbers directly connected to the router that will participate in the EIGRP route advertisements.
By default, EIGRP will redistribute IPX RIP routes into EIGRP as external routes and EIGRP routes into IPX RIP. An example of how to disable redistribution for IPX RIP updates into an EIGRP autonomous system is:
Router1(config)#ipx router eigrp 23
Router(config)#no redistribute rip
The operation of EIGRP is configurable and can be optimized to reduce WAN bandwidth utilization if necessary. The first step toward reducing EIGRP bandwidth utilization is to increase the interval between hello packets. If this value is increased, the hold time for that autonomous system also must be increased.
As previously stated, hello packets are sent by routers running EIGRP on a regular basis. These hello packets enable routers to learn dynamically of other routers on directly connected networks. In addition to learning about neighbors, the hello packets are used to identify a neighbor that has become unreachable. If a hello packet is not received from a neighbor within the hold time, the neighbor is assumed to have become unreachable. The hold time is normally set to three times the hello packet interval. To increase the hello packet interval and hold time, perform the following configuration commands:
Router1(config)#ipx hello-interval eigrp 22 15
Router1(config)#ipx hold-time eigrp 22 45
These commands executed on all routers within autonomous system 22 will increase the hello packet interval from the default 5 seconds to 15 seconds and the hold time from a default 15 seconds to 45 seconds.
In addition to the access list method of controlling SAP updates, EIGRP offers further opportunities to reduce the amount of WAN bandwidth consumed by SAP traffic. If an EIGRP neighbor is discovered on an interface, the router can be configured to send SAP updates either at a prespecified interval or only when changes occur. When no EIGRP neighbor is found on an interface, periodic SAPs are always sent. In Fig. 5-6, the default behavior of EIGRP for router 1 will be to use periodic SAPs on interface Ethernet 0, and send only SAP updates on Serial 0, when change to the SAP table occurs; this is an incremental update.
Figure 5-6: IPX EIGRP-based internetworks
This default behavior is fine for most instances; however, we can optimize the SAP traffic sent out the Ethernet 0 port of router 2 by changing the default behavior. We want to do this because the default behavior assumes that a NetWare server will be connected to any LAN interface on the router and therefore periodic updates are sent out. But in this case, the only device on the Ethernet 0 port of router 2 is an EIGRP router, which gives us the option to use incremental updates. The following commands will implement this change to default behavior for autonomous system 24 on Ethernet 0.
Router2(config)#interface E0
Router2(config-int)#ipx sap-incremental eigrp 24
The Basics of NLSP and IPXWAN Operation
An alternative to using EIGRP over WAN links is the new NLSP and IPXWAN protocols designed by Novell. The NetWare Link Services Protocol (NLSP) was introduced to address the limitations of the IPX RIP and SAP update processes, and is equivalent to using a link state protocol such as OSPF for IP routing instead of a distance vector protocol like IGRP. IPXWAN was designed to reduce the WAN bandwidth utilization of IPX routing, and is a connection startup protocol. Once the IPXWAN startup procedure has been completed, very little WAN bandwidth is utilized by IPX routing over the WAN link. NSLP will operate over IPXWAN wide area links, as will other protocols like RIP and SAP. IPXWAN does not require a specific IPX network number to be associated with the serial link; it will use an internal network number.
NLSP is derived from the OSI's link state protocol, IS-IS. The key difference between NLSP and other link state protocols is that it does not currently support the use of areas. An NLSP network is similar to having all router devices in area 0 of an OSPF autonomous system. Using a link state protocol requires each router to keep a complete topology map of the internetwork in its memory.
As changes in topology occur, routers detecting the change send link state advertisements to all routers. This initiates execution of the Dijkstra algorithm, which results in the recalculation of the topology database. Since these advertisements are sent out only when a failure of some kind occurs, as opposed to every 60 seconds as in the distance vector RIP, more efficient use of bandwidth results. The RIP/SAP routing method continues to be supported for linking different NLSP areas. Novell has stated that NLSP soon will be enhanced to support linking of separate NLSP areas directly together.
As with other link state routing protocols, NLSP routers must exchange hello packets on direct connections to determine who their neighbors are before exchanging route information. Once all the neighbors have been identified, each router sends a link state advertisement describing its immediate neighbors. After this, NLSP routers propagate network information via link state advertisements to other routers in the area. This process continues until routers become adjacent. When two routers are adjacent, they have the same topology database of the internetwork.
Once widespread adjacency is realized, the topology database is assumed correct if hello packets are continually received from all routers. Once three hello packets have been missed for a specific router, that router is assumed to be unreachable and the Dijkstra algorithm is run to adjust routing tables. Finally, a designated NLSP router on the internetwork periodically floods link state advertisements to all routers on the internetwork. This flood of packets includes sequence numbers of previous link state advertisements so that NLSP routers can verify they have the most recent and complete set of LSAs.
Before we consider specific router configurations for NLSP, we will look at the general operation of IPXWAN. Typically, NLSP and IPXWAN are implemented together, although they are not interdependent. One can be implemented without the other; NLSP does, however, require IPXWAN on serial links.
IPXWAN standardizes how IPX treats WAN links. IPXWAN can be implemented over the Point-to-Point Protocol (PPP), X.25, and frame relay. Before IPXWAN (a layer 3 protocol) can initiate, these layer 2 protocols must establish their WAN connection. Initialization of the layer 2 protocols starts a hello process to begin the IPXWAN process.
One of the routers will act as the primary requester, while the other acts as a slave that simply responds to these requests. The router having the higher internal network number value will be chosen as the primary requester. The two routers will agree on which routing protocol to use, typically RIP/SAP or NLSP, and then the requester proposes a network number to be assigned to the link. Finally the two routers agree on configuration details such as link delay and throughput available for the link.
Configuring NLSP and IPXWAN.     To set up IPXWAN and NLSP, a number of global and interface configuration commands must be executed. The prerequisites for implementing the global and interface commands for these protocols are as follows:
  Global IPX routing must already be enabled before IPXWAN or NLSP commands will be accepted.
  NLSP LAN interfaces must already have an IPX network number entry.
  IPXWAN interfaces must have no IPX network number assigned.
The following input details the necessary global commands:
Router1(config)#ipx internal-network 8
Router1(config)#ipx router nlsp
Router1(config)#area-address 0 0
The first command defines the IPX internal network number that NLSP and IPXWAN will use to form adjacencies and to decide which router will be the primary requester. This number must be unique across the IPX internetwork. NLSP and IPXWAN will advertise and accept packets for this internal network number out of all interfaces, unless restricted by a distribute list. It is worth noting that the NLSP process adds a host address of 01 to this network number, which is a reachable address when using the ipx ping command. (IPX ping is not as useful as ICMP ping; not all NetWare devices support IPX ping.)
The second command line enables NLSP on the router and the third specifies the area address to use in the form of an address and mask. As NLSP supports only one area at the moment, zero values for both the area number and mask are adequate.
This completes global configuration. IPXWAN must be enabled for each serial interface, as must NLSP for each interface that is to participate in NLSP routing.
Let's now look at the interface configuration commands for IPXWAN.
Router1(config)#interface serial 0
Router1(config-int)#no ipx network
Router1(config-int)#ipx ipxwan
The first interface configuration command will not be reflected in the configuration file, and is input only as a safety measure to make sure that no network number is assigned to the link being used by the IPXWAN protocol. The second command simply enables the IPXWAN protocol. This second command can be followed by many option arguments, but the default option with no arguments normally is adequate. The configuration shown will use the Cisco default encapsulation for the layer 2 protocol, the Cisco-specific HDLC. If you want to change this to PPP, the encapsulation ppp interface command should be entered.
Optimizing NLSP.     Although NLSP and IPXWAN are considerably more efficient than the older RIP/SAP method of disseminating network information, some optimization of IPX and NLSP operation is possible.
RIP and SAP are enabled by default for every interface that has an IPX configuration, which means that these interfaces always respond to RIP and SAP requests. When NLSP is enabled on an interface, the router only sends RIP and SAP traffic if it hears of RIP updates or SAP advertisements. This behavior can be modified by the following interface configuration commands:
  ipx nlsp rip off  stops the router from sending RIP updates out the specified interface.
  ipx nlsp rip on  has the router always send RIP updates out this interface.
  ipx nlsp rip auto  returns the interface to default behavior.
  ipx nlsp sap off  stops the router from generating periodic SAP updates.
  ipx nlsp sap on  has the router always generate periodic SAP updates for this interface.
  ipx nlsp sap auto  returns the interface to default behavior.
When SAP/RIP is used, the maximum hop count permissible is 15 by default, which can be restrictive for large internetworks. The maximum hop count accepted from RIP update packets can be set to any value up to 254 (the example shows 50 hops) with the following command:
Router1(config)#ipx maximum-hops 50
The process we will go through to customize an NLSP setup is outlined as follows:
  Configure the routers so that the least busy router is chosen as the designated router (DR).
  Assign predetermined metric values to a link to directly influence route selection.
  Lengthen the NLSP transmission and retransmission intervals to reduce NLSP network traffic.
  Lengthen the link service advertisement intervals to reduce LSA bandwidth utilization.
On each LAN interface, NLSP selects a designated router in the same way as other link state protocols do. A DR generates routing information on behalf of all routers on the LAN to reduce protocol traffic on the LAN segment. If the DR were not there, each router on the LAN would have to send LSA information to all the other routers. The selection of a DR usually is automatic, but it can be influenced by router configuration commands.
Because the DR performs more work than other routers on the LAN, you might wish to ensure that either the least busy or most powerful router always is chosen as the DR. To ensure that a chosen router becomes the DR, increase its priority from the default of 44 to make it the system with the highest priority. To give a router a priority of 55, input the following commands. (This is for a router with its Ethernet 0 port connected to the LAN determining its DR.)
Router1(config)#interface E 0
Router1(config-int)#ipx nlsp priority 55
NLSP assigns a metric to a link that is based on the link throughput (similar to IGRP). No account of load is taken into consideration. If you want to manually influence the selection of routes, you can change the metric assigned to any link with the following command (the example shows a metric of 100):
Router1(config)#interface Serial 0
Router1(config-int)#ipx nlsp metric 100
The NLSP transmission and retransmission timers are adequate for just about every installation. If you feel the need to alter these parameters, however, the following commands show how to set the hello packet interval to 20 seconds and the LSA retransmission time to 60 seconds:
Router1(config)#interface E 0
Router1(config-int)#ipx nlsp hello-interval 20
Router1(config-int)#ipx nlsp retransmit-interval 60
Similarly, the intervals at which LSAs are sent out and the frequency of the Dijkstra (the Shortest Path First) algorithm execution normally are adequate. If your network contains links that are constantly changing state from up to down, however, these values can be modified as follows to an LSA interval of 20 seconds and minimum time between SPF calculation of 60 seconds:
Router1(config)#lsp-gen-interval 20
Router1(config)#spf-interval 60
If these values are changed, they should be uniform across an entire internetwork for efficient operation.
Monitoring an NLSP/IPXWAN Internetwork.     Let's look at the pertinent configuration details of the Cisco router at the center of the internetwork shown in Fig. 5-7. This router is set up to run NLSP on all interfaces and IPXWAN on its serial link to NetWare server 3, as shown in the excerpt from its configuration file also in Fig. 5-7.
Figure 5-7: An NLSP- and IPXWAN-based internetwork
The global configuration entries enable IPX routing, set the internal IPX network number, and enable NLSP routing with the appropriate area address and mask. On each Ethernet interface, a network number is assigned and NLSP is enabled. It is assumed that the default Ethernet encapsulation type is used both by the router and the NetWare servers. The serial interface uses PPP for its encapsulation and is enabled for both IPXWAN and NLSP. The serial link has no IPX network number associated with it; it uses an unnumbered link by default.
The operation of IPXWAN can be monitored by the show ipx interface serial 0 command, which produces the output shown in Fig. 5-8.
router1>show ipx interface serial 0
Serial 0 is up, line protocol is up
IPX address is 0 0000.0010.000 [up] line-up RIPPQ: 0, SAPPQ: 0
Delay of this IPXnetwork, in tcks is 31 throughput 0 link delay
10/router1
0 IPXWAN delay (master owns):31
20 IPXWAN Retry limit:3
RIP Unnumbered
Slave: Connecty
State change reason: Received Router Info Req as xlave
Last received remote node info: 15/NW3
Client mode disabled, Static mode disabled, Error mode is reset
IPX SAP update interval is 1 minute
IPX type 20 propagation packet forwarding is disabled
Outgoing access list is not set
IPX Helper list is not set
SAP GNS procerssing enabled, delay 0 ms, output filter list is not set
Figure 5-8: The show ipx interface serial command 0 for an IPXWAN interface
The IPXWAN node number is defined by the internal IPX network number and the router's configured hostname, which in this instance is 10/Router1. The IPXWAN state indicates that it is a responder (slave), rather than a requester and is connected to a NetWare server named NW3, configured with an internal network number of 15.
To monitor the NLSP routes, issue the show ipx route command to view the IPX routing table, as shown in Fig. 5-9.
router1>show ipx route
Codes: C - connected primary network, c - connected secondary network
S - Static, F - Floating static, L - Local (internal), W - IPXWAN, R - RIP, E - EIGRP, N - NLSP, X - External, s - seconds, u - uses
4 total IPX routes. Up to 1 parallel paths and 16 hops allowed
No default route known
800(SAPE0
111(PPP)As1
5[20] [02/01] via3.0000.0210.98bc30sE0
Figure 5-9: Monitoring NLSP routes
This routing table labels the internal network number with an L indicator, the directly connected Ethernet networks with a C indicator, NLSP routes with an N indicator, and the IPXWAN network with a W indicator. These two commands give you all the information that is necessary to determine the state of NLSP and IPXWAN routing.
NetBIOS over IPX
The IPX packet type 20 is used to transport IPX NetBIOS packets through a network. NetBIOS was designed as a fast and efficient protocol for small individual networks. As such, NetBIOS does not use a network number when addressing a destination node; it is assumed that the destination is on the same network segment. NetBIOS implements a broadcast mechanism to communicate between nodes. Broadcasts normally are blocked by a router, so if we want broadcasts to traverse a router, we must specifically configure it to do so. In NetBIOS networking, nodes are addressed with a unique alphanumeric name. If two NetBIOS nodes need to communicate via a Cisco router, it is possible to configure the router to forward IPX packet type 20 broadcasts between specified networks. Figure 5-10 provides an example of this.
Suppose that in this network we want NetBIOS nodes Eric and Ernie to communicate. This means we have to enable IPX packet type 20 to traverse the router between network aaa and ccc. As no NetBIOS nodes are on network bbb, no type 20 packets need to be sent onto that network. The relevant parts of a router configuration are shown in Fig. 5-11.
The command that enables reception and forwarding of NetBIOS packets on an interface is the ipx type-20-propagation command configured for interfaces Ethernet 0 and Ethernet 2.

 


 
Books24x7.com, Inc © 2000 –  Feedback